IBIS Macromodel Task Group Meeting date: 21 May 2024 Members (asterisk for those attending): Achronix Semiconductor: Hansel Dsilva Amazon: John Yan ANSYS: * Curtis Clark * Wei-hsing Huang Aurora System: Dian Yang Raj Raghuram Cadence Design Systems: * Ambrish Varma * Jared James Dassault Systemes: Longfei Bai Google: Hanfeng Wang GaWon Kim Intel: * Michael Mirmak Kinger Cai Chi-te Chen Liwei Zhao Alaeddin Aydiner Keysight Technologies: Fangyi Rao Majid Ahadi Dolatsara Stephen Slater Ming Yan Rui Yang Marvell: Steve Parker Mathworks (SiSoft): Walter Katz Graham Kus Micron Technology: Justin Butterfield Missouri S&T: Chulsoon Hwang Yifan Ding Zhiping Yang Rivos: Yansheng Wang SAE ITC: Michael McNair Siemens EDA (Mentor): * Arpad Muranyi * Randy Wolff Teraspeed Labs: [Bob Ross] Zuken USA: * Lance Wang The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - Arpad noted that a recent device vendor inquiry about support for MIPI C-PHY modeling had prompted private discussions about renewed interest in: - C-PHY - [Ramp] (T-coils) - multi-level stimulus for [External Model] and [External Circuit] ------------- Review of ARs: Michael: Send revised BIRD 230 to Open Forum. - Done. It was submitted as BIRD 230.1. Michael: Prepare a list of BIRDs for the next IBIS version and share it with the Open Forum. - Done. Michael reported that this had been discussed at the most recent Open Forum meeting. Michael said one question is whether to call the next version IBIS 8.0 (as opposed to 7.3). He noted that all BIRDs introduced since IBIS 7.2, with the exception of BIRD220, are either already approved or expected to be approved soon. If the Open Forum agrees then the Editorial task group could begin work on the next version of IBIS soon. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the April 30th meeting. Curtis moved to approve the minutes. Michael seconded the motion. There were no objections. -------------- New Discussion: Fixing [Clock Pins]: Michael said he had not received any new feedback on his proposal. He said he has a minor clarification BIRD proposal that could resolve the current short- comings with respect to DDR Controllers. However, he doesn't want to propose that change until he is sure it won't overly constrain us in the future. Michael said he would like feedback from people on what types of timing relationships, particularly with respect to memory, should be included in this keyword. He said many EDA tools have wizards that need timing information to be provided by the user. Could it be specified in an IBIS model, and if so, what form should it take? The [Clock Pins] keyword has some provisions for providing this information, but we need to avoid hard coded numbers that limit our ability to support devices with varying capabilities. Arpad elaborated based on some private discussions with Michael. He said that his organization, for example, uses a Verilog based .v file to provide this timing information. He said Michael had reported that different EDA tools seem to have their own formats for providing timing information. Should we develop a standardized way to pass this information in an IBIS-like format along with the IBIS models, so it's portable between vendor platforms, or are we happy with everyone doing things their own way? Michael said his organization would prefer not to have to provide timing information in 4 or 5 different formats depending upon the EDA tool their customer preferred. Michael said that if fixing the known shortcoming with respect to controllers is the only issue, then he has a straightforward fix for [Clock Pins]. It would use the relationship column to introduce clock "groups" analogous to [Model Selector], which would allow different clock pin to data pin relationship groupings to be selected. However, we may not want to adopt this change if it will give up flexibility that we might need later. Do we want to be able to specify actual timing relationships and timing information? How could we set up selectors that support different speeds and timing specifications, not just different clock-data pairings? Randy said that the last time we put something in the IBIS specification that was tied to a standard was the [Receiver Thresholds] keyword added in the DDR2|3 timeframe. He said the issue that arose was that threshold levels were specific to a data rate. You might have one IBIS [Model] that covered a bunch of data rates, but if you wanted to include Rx thresholds for every data rate you had to duplicate the [Model] over and over just to provide a different set of thresholds in each. He agreed with Michael that we need something more flexible than hardcoding information into a [Model] keyword. Arpad asked whether the content of the timing file should be standardized, or whether we should support everybody's different formats? Michael said that supporting multiple formats would get us into the same morass we ran into with multi-lingual models. If you make it too flexible, then no one uses it. Michael said he would prefer one standard format that would work in any tool. Michael suggested that one path forward would be to ask whether major EDA vendors would be willing to send examples of the formats they currently use for timing information. If we could get a sampling of existing EDA tool formats, and information about the kinds of data system designers think they need and device vendors are willing to provide, it would be helpful in coming up with a standardized format. Arpad said he thought his organization could provide some file format examples. Ambrish and others said they would check with the respective experts in their organizations. BIRD220 update: Randy reported that this was discussed at the last Open Forum meeting. He said Chulsoon had indicated that his team is investing further. They expect to bring something back to ATM, possibly in June. MIPI C-PHY: Arpad said a recent post to the ibis-users list from a MIPI C-PHY vendor had started discussions about C-PHY support in IBIS. He said that in his experience C-PHY is a unique and unusual standard, and it would be a major undertaking to generate a syntax to support it within IBIS. He asked whether anyone had any insight into whether it would be worth the effort. Randy said that he'd seen an increasing number of people using C-PHY, and he and Wei-hsing noted several past IBIS Summit presentations on the topic. Michael reported that people had approached him at DesignCon and asked when IBIS would be able to support C-PHY. Ambrish said it's a fundamentally different technology. It's a 3-wire system, and it is almost as though it defines the way the stimulus would be presented. It's really outside of IBIS and at a higher level of the stack. Unless we want to get into encoding, etc., he wasn't sure this was a topic for IBIS. He asked whether anyone with experience might present an introduction. Arpad said he could prepare an introductory presentation based on his past experience with C-PHY. He agreed that it's a major undertaking, and we'd first have to decide that we think it's worth the effort. The group agreed that we need to do some background work to confirm the industry need for IBIS support of C-PHY, make sure it's still a hot topic, etc. Wei-hsing noted a presentation from the November 2020 China IBIS Summit that described C-PHY modeling with multiple conventional IBIS buffers. He asked whether Arpad was envisioning incorporating 3 states into a conventional IBIS [Model]. Arpad said that C-PHY Tx signals are basically PAM3, with a high, middle, and low level. He said the IBIS [Model] doesn't natively support that, but he had created a PAM3 implementation usings [Submodel]s, though in a non- compliant way. He said the easiest way to support PAM3 in IBIS might be along those lines, and then we would also need support for a 3-level stimulus. Arpad and Randy noted additional complications with C-PHY including the fact that it uses 3 single-ended buffers (a triplet) on the Tx side and measures differentially across the 3 wires with 3 Rx buffers. Arpad said it has a rigorously defined state machine that only allows certain combinations of states between the 3 levels on each of the 3 lines. Should IBIS get involved with this or just expect the EDA tool to handle the CPHY Tx states properly? Ambrish asked why IBIS would get involved with any of this if the MIPI specification does it already. Perhaps we should just worry about defining terminations so that we can have 3 different IBIS [Models] for the individual Txs, a three-level curve coming out of each Tx, and the proper Rx terminations. Aside from that, we should leave the rest to the MIPI specification. Randy agreed that our concern is really about adding support for defining the buffers themselves in a compliant way. Arpad noted that he had previously presented a multi-level IBIS analog buffer modeling proposal. He said he had worked on a BIRD draft, but it was not ready yet, and there had not been much interest. He said if we want to support C-PHY with regular I-V and V-T tables, then we would probably need his BIRD. Arpad asked whether this topic is something we should consider in the AMI sections of the specification, or should it be in the I-V and V-T analog sections? Ambrish said the I-V and V-T information is needed for the channel characterization even if we handle C-PHY with AMI. Arpad said that for AMI we just need one overall IR derived using the maximum swing from the Tx. Once we have that, the levels from the Tx in a PAMn AMI scenario are handled by using equally spaced levels in the input stimulus waveform to the Tx. If we were to try to support multi-level signaling in the I-V and V-T tables, then we would likely need additional sets of I-V data and also different V-T curves for each of the transitions amongst the various levels. It's not particularly challenging to do, but the model would get much bigger. Wei-hsing and Ambrish noted that CTLE and FFE are also defined in C-PHY, so we might need to use AMI. Arpad countered that the FFE in C-PHY is currently similar to the old pre-emphasis and de-emphasis cases IBIS handled with [Driver Schedule]. If the C-PHY FFE were ever to be extended to additional taps, then this approach might not be practical, however. Arpad said CTLE could also be handled without AMI, perhaps with an S-parameter model, for example. So, we aren't necessarily forced into the AMI domain to handle C-PHY. Ambrish noted that if anything utilizes DFE then we would need AMI type modeling. Arpad said that he had seen several presentations on CORD signaling. He said that C-PHY could be considered a subset of CORD signaling, and he wondered whether we would want to consider a more general support for CORD signaling if we look into C-PHY support. Arpad asked everyone to think about these topics and investigate further. - Michael: Motion to adjourn. - Curtis: Second. - Arpad: Thank you all for joining. New ARs: None. ------------- Next meeting: 28 May 2024 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives